Short Message Service (SMS) has been very successful in the Global System for Mobile communication (GSM) second generation (2G) system, wherein it is possible to execute non realtime text transmission by means of GSM terminals, e.g. from an internet computer terminal to a mobile phone or from one mobile phone to another. This easy to use service for non realtime text transmission shall be succeeded to in 2.5G and third generation (3G) mobile systems by a non real-time Multimedia Message Service (MMS). With MMS, users are allowed to send and receive Multimedia Messages (MM) exploiting the whole array of media types available today e.g. text, images, audio, video while also making it possible to support new content types as they become popular.
A non-realtime MM, or otherwise called store and forward MM, is a combination of one or more different media elements in a multimedia presentation that can be transferred between devices of users without the requirement for the need to be transferred in realtime. The non-real-time multimedia messaging service shall be capable of supporting current and future multimedia messaging services, and exploit the advances being made in the world multimedia community, with additional mobile requirements.
3rd Generation Partnership Project (3GPP) Technical Specification 22.140 V4.2.0 (2002-03) and 3GPP Technical Specification 23.140 V4.6.0 (2002-03) describe the current state of standardization activities for MMS. For sending a MM from an originator to a recipient, the following procedure can be used: A user agent (UA), i.e. an application residing on the originator's User Equipment (UE) or a device attachable to the UE of the originator sends the MM comprising multimedia content and an address of the recipient to an originator MMS Relay/Server (R/S). The originator MMS R/S forwards the MM content to a recipient MMS R/S that subsequently notifies an UA residing on the UE of the recipient. The notification does not contain the MM but a reference to the actual MM. The reception of the MM notice is acknowledged by the recipient MMS UA to the recipient MMS R/S and the MM can then be retrieved by the recipient MMS UA. The retrieval of the MM and the reading of the MM by the UA of the recipient are acknowledged to the recipient MMS R/S. A MM delivery report comprising an identification of the original MM, the recipient address, time stamping, and the delivery status can be generated by the recipient MMS R/S and sent to the originator MMS R/S. The originator MM R/S can send the delivery report to the originator MMS UA, e.g. for indication of the delivery of the MM to the originator MMS UA. A similar procedure is described for sending a read reply report that is generated at the recipient MMS R/S when the MM is read by the recipient.
Sending a MM from one originating UA to multiple recipient MMS UAs is possible. One alternative is to address the MM to multiple recipient MMS UAs and to perform MM replication right at the originating MMS UA. Another alternative is to send the MM and the addresses of the multiple recipient MMS UAs from the originator MMS UA to the originator MMS R/S. Replication of the MM is executed at the originator MMS R/S even for recipient MMS UAs that are served by the same recipient MMS R/S. The procedure continues as described before for sending the replicated MMs to one or more recipient MMS R/S that subsequently notify the recipient MM UAs for retrieval of the MM. Both procedures are similar to email distribution to a number of receivers. Either the entire list of receivers is included and multiple emails are send to each of the receivers or a list-server like majordomo is used. A list server maintains lists of addresses of users subscribed to one or more groups. Each group can be identified by a group address. An email addressed to one of the groups comprises the corresponding group address on base of that and the corresponding list the list-server can retrieve the corresponding user addresses. A copy of the email is sent to each of the corresponding user addresses.
The aforementioned procedures are not very efficient. In the case of MM delivery to multiple recipient MMS UAs, the notification and then the recipient MMS UA triggered retrieval sequence becomes a limitation. In the case a large number of recipients UAs gets a notification for the same MM, the probability is rather high that all or a high fraction of the recipient MMS UAs initiate the retrieval of the MM immediately after the reception of the notification. In this situation, the recipient MMS R/S sends per recipient MMS UA that requests a retrieval of the MM, a message for retrieval comprising the MM leading to high load of the recipient MMS R/S and possibly even congestion of the network, especially on the scarce and expensive radio networks between the recipient MMS R/S and the recipient MMS UAs. In addition, acknowledgements of the retrieval or read replies sent from the recipient MMS UAs that have received the MM and read the MM, respectively, initiate the generation of delivery and read-reply reports, respectively, with the number of delivery or read reply reports amounts to the number of recipients UAs that have received and read the MM, respectively. The reports can be further sent to the originator MMS R/S and to the originator MMS UA leading to congestion of the network between those entities and overload of the entities themselves.
A so-called MM1_submit.REQ message comprising addresses and a MM sent from the originator MMS UA to the originator MMS R/S contains flags to indicate whether a delivery report, reply-charging and read reply is requested. However, these are simple yes/no flags without any granularity indications on how the originator MMS UA would like to receive the report. Especially, there is currently no way to control the amount of delivery reports and read reply reports to the originator MM R/S and originator MMS UA triggered by acknowledgements and read-reply messages by the recipient MMS UAs to the recipient MMS R/S. Especially in the case of multiple recipients, the amount of acknowledgements and reports and the messaging needed for transmitting the acknowledgements and reports can lead to a high load of the network entities involved resulting in overload situations or performance reductions.